1. Field of the Invention
The present invention relates to a method, system, and program for replacing a storage unit using, in one embodiment, point-in-time snap copy and a storage unit swap.
2. Description of Related Art
One or more hosts may store large quantities of data in a group of storage units, which is typically controlled by a storage controller. Examples of such a storage controllers include the IBM TotalStorage® Enterprise Storage Server® (ESS) and the IBM System Storage DS8000 series. A storage controller such as the ESS or DS8000 may provide a number of functions accessible by the hosts for protecting data, backing the data up, and making the data available for use.
Amongst the functions which may be provided by a storage controller is a data preservation function which can preserve an identified set of data at a particular point in time. For example, the ESS and DS8000 series storage controllers support a point-in-time snap copy function referred to as “FlashCopy” which enables a copy to be made of a set of tracks in a source volume. One feature of such point-in-time snap copy functions is that the data of the copy is frequently made immediately available for read or write access. The identified data may be for example, a set of tracks which can consist of an entire volume, a data set, or just a selected set of tracks, for example.
In one mode of a point-in-time snap copy function, a copy of all of the data to be preserved at the particular point in time, is made by copying the identified data from the source volume to the target volume, typically in a background copy mode. If a host attempts to read data from the target volume before it is copied over to the target volume, the read operation is directed to the source volume containing the original data. If a host attempts to update the data on the source volume which is being preserved on the target volume, that update is typically temporarily delayed until the old data to be updated is copied to the target volume for preservation. Once a particular data location of the set of identified data on the source volume has been successfully copied to the target volume by the background copy operation, that data location on the source volume is freed for subsequent immediate updating by a host.
Storage controllers can also provide continuous availability of production data in the event of a sudden catastrophic failure at a single point in time or data loss over a period of time. In one such disaster recovery system, production data is replicated from a local site to a remote which may be separated geographically by several miles from the local site. Such dual, mirror or shadow copies are typically made in a secondary storage device at the remote site, as the application system is writing new data to a primary storage device usually located at the local site. Different data replication technologies may be used for maintaining remote copies of data at a secondary site, such as International Business Machine Corporation's (“IBM”) Metro Mirror Peer to Peer Remote Copy (PPRC), Extended Remote Copy (XRC), Coupled XRC (CXRC), Global Copy, and Global Mirror Copy.
In data mirroring systems, data is typically maintained in volume pairs, comprising a primary volume in a primary storage device and a corresponding secondary volume in a secondary storage device that includes an identical copy of the data maintained in the primary volume. The primary and secondary volumes are identified by a copy relationship in which the data of the primary volume, also referred to as the source volume, is copied to the secondary volume, also referred to as the target volume. Primary and secondary storage controllers may be used to control access to the primary and secondary storage devices.
Tivoli Storage Productivity Center for Replication is an example of an application that customers may use to manage planned and unplanned outages. The Tivoli Storage Productivity Center for Replication application can detect failures at the primary storage subsystem which may be at a local site, for example. Such failures may include a problem writing or accessing primary storage volumes at the local site. When the Tivoli Storage Productivity Center for Replication recovery application detects that a failure has occurred, it can invoke or cause to be invoked a storage unit swapping function, an example of which is the IBM HyperSwap® function. This function may be used to automatically swap processing for all volumes in the mirrored configuration from the local site to the remote site. As a consequence of the swap, the storage volumes at the remote site which were originally configured as the secondary volumes of the original copy relationship, are reconfigured as the primary volumes of a new copy relationship. Similarly, the storage volumes at the local site which were originally configured as the primary volumes of the original copy relationship, may be reconfigured as the secondary volumes of the new copy relationship, once the volumes at the local site are operational again. In anticipation of an unplanned swap, information may be passed by the Tivoli Storage Productivity Center for Replication application to the HyperSwap function which can detect a failure on its own (i.e. without further assistance from Tivoli Storage Productivity Center for Replication application) and perform the HyperSwap function.
In various situations, it may be appropriate to switch input/output (I/O) operations directed to one or more volumes of a data storage to corresponding volumes of the same or a different source storage without impacting the users' I/O production work. Various products are available for migrating data from an existing storage subsystem to a new storage subsystem with little or no disruption to ongoing input/output (I/O) operations or to a disaster recovery capability which may be provided in case of a failure over the course of the data migration. Examples of such data migration products include TDMF (Transparent Data Migration Facility) by IBM Corporation or FDRPAS by Innovation Data Processing.